Why KYAML or actually why not

Being and excited about a new Kubernetes Release I went and read the release notes of 1.37 and saw the KYAML section. As an avid lover of pushing boundaries w.r.t. to languages and technologies this seemed to sound interesting. Especially since YAML+JSON being the defacto data exchange and description language for Kubernetes is a problematic - in my humble opinion. More on why along the way.

So I went and dove into the KEP 5295 motivation, to see what is about. The claim is YAML is easy to read, which I would immediately disagree if you worked with Kubernetes for long enough and had Custom Resources on the medium to bigger end. It is frankly not very nice to read, especially if you have lists. This is helped by tools that let you collapse subitems/sublists which you do not want to view but that is about it. Then they - in my reading of it - broadly claim that YAML as-is is too broad and mistakes can happen easily. I can agree on that, especially given the examples the authors provide.

Now I wanted to see how they actually intend to address their stated issues and whether it looked like a meaningful improvement to me.

To condense the already short proposal, here are some keypoints:

1. Always quote strings (cool, this just became more tedious)
2. Always [] for lists and {} for objects

To make it more clear here is an example from the KEP on how this effectively looks like

---
{
  apiVersion: "v1",
  kind: "Service", # Comments allowed because YAML
  metadata: {
    creationTimestamp: "2025-05-09T21:14:40Z",
    labels: {
      app: "hostnames",
    },
    name: "hostnames",
    namespace: "default",
    resourceVersion: "37697",
    uid: "7aad616c-1686-4231-b32e-5ec68a738bba",
  },
  spec: {
    clusterIP: "10.0.162.160",
    clusterIPs: [
      "10.0.162.160",
    ],
    internalTrafficPolicy: "Cluster",
    ipFamilies: [
      "IPv4",
    ],
    ipFamilyPolicy: "SingleStack",
    ports: [{
      port: 80,
      protocol: "TCP",
      targetPort: 9376,
    }],
    selector: {
      app: "hostnames",
    },
    sessionAffinity: "None",
    type: "ClusterIP",
  },
  status: {
    loadBalancer: {},
  },
}

My hontest opinion and feelings? I am (a) not convinced and (b) actually disappointed. Why? This is an issue I care about - yet I do not participate nor push this in the community, would be a fair criticism - and this change adds complexity to kubernetes yet merely introduces something like JSONC (yes there are a multitude of JSON variants, one of which allows comments). It does not address issues that "cool" languages like CEL, Nickel or PKL address, e.g., types, less redundancy, LSP-like tooling and linting instead of having to use something like JSON or YAML schemas which are way less ergonomic to writing a type/contract in Nickel or PKL.

You might say Nickel is niche and I would agree, but PKL and CEL are definitely not. And these projects integrate reasonably well into an existing YAML and/or JSON ecosystem.

To conclude this mild rant-like post: I really hope we get something better in the future and I hope KYAML does not gain traction, because the stated issues of the authors are probably better addressed using schemas and linters in the meantime instead of using what I consider esoteric KYAML.